Fixes #6855 (closed by the reporter once they realized they could just disable the feature to stop it from breaking their system)

Problem

With spring-integration instrumentation enabled, Spring components that recover a
message's MessageHeaderAccessor stop finding it. StompBrokerRelayMessageHandler
is one such component — it requires the accessor and throws:

No header accessor (not using the SimpMessagingTemplate?)

which breaks STOMP broker relaying. The usual workaround is
otel.instrumentation.spring-integration.enabled=false.

Root cause

preSend() rebuilds the message so it can carry the injected trace context:

return MessageBuilder.fromMessage(message)
    .copyHeaders(messageHeaderAccessor.toMessageHeaders())
    .build();

toMessageHeaders() returns plain MessageHeaders. The link between a message and
its accessor lives in MutableMessageHeaders, so rebuilding this way silently drops
it and MessageHeaderAccessor.getAccessor(message, ...) returns null downstream.

Fix

Rebuilding now distinguishes three cases:

• No bound accessor, or an ErrorMessage — keep the existing MessageBuilder
  path. ErrorMessage does so because from 5.3 on MessageBuilder carries its
  originalMessage over into the rebuilt message and createMessage cannot.
• Mutable headers — getMutableAccessor() returns the message's own accessor,
  so the context has already been written in place; return the message unchanged.
  Rebuilding here would seal the caller's message.
• Otherwise — seal the accessor copy and hand over its own MessageHeaders.
  Sealing gives the new message an id and stops it sharing mutable headers with
  the accessor, while createMessage preserves the binding.

All APIs used are public at the 4.1.2 compile floor.

Tests

AbstractTracingChannelInterceptorTest in the testing module, with thin subclasses
in library and javaagent, following the existing AbstractSpringIntegrationTracingTest
pattern. Messages are sent through a real channel and asserted on what the handler
receives, over both a direct and an executor channel.

Covers context propagation, payload/header preservation, message id, header
immutability, cross-send header isolation, ErrorMessage type and originalMessage,
STOMP native headers, and accessor preservation for mutable and immutable messages.

Each of the three branches was removed in turn to confirm a test fails for each.

Verification

testLatestDeps is capped at 5.+ by a documented limitation, so muzzle is the only
coverage of 6.x/7.x. The assertInverse boundary is unmoved at 4.1.0.

Behaviour notes

Timestamp. On the sealed path the rebuilt message has no timestamp, where the
previous code generated one. setEnableTimestamp is protected so it cannot be
restored externally. This matches Spring's own idiom — accessor-bound messages built
through createMessage carry no timestamp, and the input messages in this shape don't
either — but it is a change. The message id is present; for mutable accessor-bound
messages id was already absent before this change.

Accessor subclasses. Only subclasses that override createAccessor are restored,
because getMutableAccessor delegates to it. Every Spring accessor intended to survive
a mutable copy does so; a subclass that doesn't will still resolve to the base type.

ErrorMessage. originalMessage preservation is guaranteed structurally rather than
by assertion at the baseline: neither the constructor that populates it nor
getOriginalMessage() exists at the 4.1.2 compile floor, so that test is
reflection-based and gated on testLatestDeps().

Not included

A test driving StompBrokerRelayMessageHandler end to end. Its accessor check sits
behind an isBrokerAvailable() guard, so without a live broker connection the handler
returns early and such a test would pass vacuously. The StompHeaderAccessor scenario
covers the precondition instead, including the native headers a STOMP frame actually
transmits. Happy to add a broker-backed test with guidance.